This is a first step in improving the performance of the upgrade tool.
Essentially let's cache the incoming candidate to the outgoing migration
based on the given inputs.

Notes: this is technically going to be slower now, because the
`location` will be different for every candidate right now.

In the next commits we will make sure to drop the `location` from the
cache (increasing the cache hits) and checking whether the migration is
safe ahead of time.

Instead of checking whether a candidate migration is safe during each
migration step, we can do it all up front. To make things worse, we did
check the safety in some migrations, but not in others which means that
we could still be performing unsafe migrations.

The big issue with "unsafe" migrations is where we use very small
classes such as `blur` or `visible` and they can be used in non-Tailwind
CSS contexts. Migrating these will result in unsafe migrations.

The moment we use variants, modifiers, arbitrary values the chances that
these are actual unsafe migrations are so low. We can use that as a
heuristic to check whether a migration is safe or not.

When we are dealing with `blur`, `visible` or `flex` we can apply the
other, existing, safety checks.

Once we know that a migration is unsafe, we will skip the migration.

Bonus points: this also takes the `location` information out of the
cache, which means that the cache will be smaller and increase cache
hits tremendously.

Before even gathering context of the candidate's surroundings, we can
already look at the candidate itself to know whether a migration will be
safe.

If a candidate doesn't even parse at all, we can stop early.
If a candidate uses arbitrary property syntax such as `[color:red]`,
there is like a 0% chance that this will cause an actual issue..

and so on.

When we do this upfront, then other migrations don't have to worry about
whether a candidate is potentially _not_ in its minimal canonicalized
form.

Additionally, this allows us to cleanup the main migrate function
itself, because we don't have to re-parse and re-print if nothing
changed in the meantime.

This is now implicitly handled by the `migrateCanonicalizeCandidate`
migration because we are parsing and printing the candidate.

Except if the `attr` is a `class`

When you have something like:
```
if (!duration) {}
```

It could be that we migrate this to:
```
if (duration!) {}
```

Hopefully our safety checks do not do that though. But in the event that
they do, the `!duration` should not be converted to `duration!` because
that class simply doesn't exist.

It wil parse correctly as:
```
[
  {
    "kind": "functional",
    "root": "duration",
    "modifier": null,
    "value": null,
    "variants": [],
    "important": true,
    "raw": "!duration"
  }
]
```

And that's because the `duration-<number>` _does_ work and produces
output. But this on its won won't produce any output at all.

If that's the case, then we can throw away any migrations related to
this and return the original value.

When a candidate doesn't parse, we throw it away. However, if you are in
a Tailwind CSS v3 project then it could be that we are dealing with
classes that don't exist in Tailwind CSS v4 and will be migrated later.

It could also be that we are dealing with legacy syntax, e.g.:
`tw__flex` if you have a custom variant separator.

This fixes that by only bailing in Tailwind CSS v4 and up.

Otherwise the normal `class` would also be considered invalid, which is
not what we want.

In order to properly parse the value, we already had to make sure that
`group` and `peer` exist in the framework during a Tailwind CSS v3
→ Tailwind CSS v4 migration.

We now also verify that the actual produced class is valid, for this we
use `@apply` internally, but because of the `return null` this was
considered invalid.

This fixes that by making sure that we have some declarations, in this
case I used a random key like `--phantom-class: group`.

Then to make sure that `group` and `group/foo` are considered distinct
classes, I also added the modifier to the equation.

The color is called `superRed` which is migrated to `super-red`, but we
used the color `red-superRed` and expected `red-super-red` which doesn't
exist in the theme and therefore wasn't migrated.